昨天那二十七封信，直覺的解法是再開幾個信箱：security-report@、bounty@、vuln@，各收各的。

這個解法會失敗，而且失敗得很快。

通報者不會照你的分類寄

原因很簡單：分類是你的內部問題，你不能把它外包給通報者。

一個研究人員手上有一個弱點。他不知道那件事在你們公司算「一般通報」還是「法定緊急通報」，因為那取決於你們賣了什麼、賣到哪裡、有沒有正在被利用。這些他都不知道，也不該知道。

汽車召回的專線只有一支。車主打進去不必先判斷自己那台在不在召回批次，他報車身號碼，判斷是原廠的事。

多開入口還有兩個現實代價。**要監看的地方變多，漏接的機率跟著變高。**而且從法遵角度看，Annex I Part II(6) 要的是「弱點通報聯絡點」，單數；入口散開之後，要證明「公司在某月某日某時知悉」會變得更難。

對外：一個地址，三個地方寫著它

入口統一的具體做法很單純。

一個信箱：security@ 你們的主網域。不要用個人信箱，不要用部門別名，不要是某個人的離職就會消失的東西。

一個網頁表單：放在官網，欄位設計明天講。表單的價值在於它可以強迫必填欄位，而信件不行。

一份 security.txt：這是投報率最高的一件事，半小時做得完。

放在 https://你的網域/.well-known/security.txt：

Expires 是 RFC 9116 的必填欄位，而且它真的會過期。過期的 security.txt 比沒有更糟，因為它告訴研究人員這裡沒人管。設一年，然後現在就把更新日期排進行事曆。

對內：三條軌道

入口統一之後，分軌的動作由你做，在收件之後、處理之前。

三條軌的關鍵設計是只能往上升級，不能往下降級。

案件一旦進了軌一，就照軌一走完，即使後來研判不成立也要留下「為什麼撤回」的紀錄。允許往下降級，等於允許有人為了少做一點事而把案件重新分類，而那正是稽核時最難解釋的一種紀錄。

CVD 政策的最短可用版本

Annex I Part II(5) 要求建立並執行協調揭露政策。很多人以為要寫十幾頁，實際上五段就能上線。

**一、範圍。**哪些產品、哪些網域適用。寫清楚也等於寫清楚不適用的部分。

**二、怎麼回報。**地址、希望的內容（型號、韌體版本、重現步驟）、可接受的語言。

**三、我們承諾什麼。**多久確認收到、多久給初步回覆、多久更新一次進度。

**四、我們請你做什麼。**不要在正式環境測試、不要存取他人資料、揭露前給我們多少時間。

**五、安全港。**善意研究不會被提告。這一段決定研究人員願不願意先找你。

第三段是最多人寫壞的地方。**承諾時限要寫做得到的。**寫「24 小時內確認收到」看起來很專業，但如果你的團隊週末沒有人看信箱，這句話就是自己給自己挖坑。寫「三個工作日內確認收到」不丟臉，做不到才丟臉。

為什麼獎勵計畫現在不該開

這題很常被問，而且問的人通常已經在心裡決定要開了。

三個理由。

**第一，它會把案件量放大一個數量級，而你的分流還沒建好。**在垃圾場上蓋一座更大的垃圾場，不會變乾淨。

第二，它需要另一套完整流程：重複判定、嚴重度定級、付款、跨境稅務、爭議處理。這些跟弱點處理是兩回事，而且多半不在資安團隊的能力範圍內。

**第三，也是最重要的：獎勵計畫吸引的是廣度掃描，不是深度研究。**賞金獵人的理性策略是用工具掃很多目標、快速提交低垂的果實。而你現在最需要的，是有人願意花兩週逆向你的韌體。這兩種人被不同的東西吸引。

我的建議是先跑六個月不含獎金的 CVD，把三軌的實際流量數據累積起來，再決定要不要開。先有分流，再有獎勵。

交付物：三軌分流規格

一頁，貼在流程文件的第一節。

三個提醒。

**第一，「進入條件」要寫得讓別人也判得出來。**如果只有你判得出來，那不是流程，是你的個人習慣。

**第二，軌三也要有結案條件。**很多人只設計前兩軌，結果非案件那一堆永遠躺在信箱裡，變成心理負擔。三十秒判定、標記、封存，也是一種結案。

**第三，這張表填完先跑兩週再公告。**內部跑順了再對外承諾時限，順序反過來會很痛。

明天 Day 15：L0，讓系統先擋掉一半

去重、必填欄位、垃圾與釣魚過濾、非資安轉送、速率限制。表單的必填欄位怎麼設計，決定你後面要補多少件。

順便問一句。你們的官網：

有 /.well-known/security.txt 嗎？

（a）有，而且 Expires 還沒過期　（b）有，但很久沒更新　（c）沒有，但有 security@ 信箱　（d）都沒有

留個字母就好，不用打長篇。（b）比想像中多，而且過期的比沒有更容易讓人放棄找你。

這系列每天更新，覺得有用的話幫忙訂閱，謝謝。

參考：Regulation (EU) 2024/2847 第 14 條與 Annex I Part II(5)(6)；security.txt 欄位依 RFC 9116；ISO/IEC 29147 弱點揭露、30111 弱點處理。三軌設計與獎勵計畫判斷為個人整理，非法規明文。